Home NodeB is a small base station with low power deployed in indoor places such as houses, offices, etc., and its main function is to provide higher service rate to users and reduce costs of high rate services while making up for defects of coverage of distributed cellular wireless communication systems. The advantages of the home NodeB is convenience, low output power, plug-and-play, etc.
Home NodeB systems almost can be applied in all mobile communication networks, such as CDMA1X and CDMA2000 networks using a series of standards of code division multiple access (CDMA for short) in the 3rd Generation Partnership Project 2 (3GPP2 for short), 2nd Generation (2G) networks such as global system for mobile communications (GSM for short) in the 3rd Generation Partnership Project (3GPP for short), 3rd Generation (3G) networks such as wideband code division multiple access (WCDMA for short) systems, and long term evolution (LTE) mobile communication networks of the all-Internet Protocol (IP for short) which almost all operators will choose to use in the future, as well as Worldwide Interoperability for Microwave Access (WiMAX for short) mobile communication networks which use almost the same modulation technology as the LTE systems.
FIG. 1 is a block diagram of an existing home NodeB system.
As shown in FIG. 1, a user equipment (UE for short) can access a core network (CN for short) via a macro cell network to execute corresponding voice services, or execute data services by accessing to the Internet.
However, in order to solve coverage of a home indoor network, the UE can also access an IP backhaul network via a home NodeB access point, i.e., micro base station access point, also referred to as femto access point (Femto AP), access a home NodeB gateway, also referred to as femto gateway (Femto GW), at a service location via the IP backhaul network, and then access the core network at the service location to access to the Internet via the core network.
A security gateway (SeGW for short) at the service location can be provided between the Femto AP and the Femto GW at the service location (serving Femto GW for short), and the Femto AP establishes an IP security tunnel with the serving Femto GW via the security gateway at the service location (serving SeGW or serving security gateway for short).
A Femto authentication, authorization and accounting (AAA for short) system at the service location is connected to the serving security gateway to assist the Femto AP in establishing the IP security tunnel with the serving security gateway.
A home NodeB management server, referred to as femto management server (FMS for short), at the service location is connected to the Femto AP by the serving security gateway and used for configuring parameters of the Femto AP to ensure normal operation of the Femto AP. The Femto AP and the femto management server at the service location (serving FMS for short) configure the parameters using the home network protocol TR069 of a wideband forum.
The Femto AP can also directly access the Internet. In addition, according to different gateway types, the Femto GW can access three types of core networks, circuit switched (CS for short) network, IP Multimedia Core Network Subsystem (IMS for short) network and packet switched (PS for short) network, respectively.
Since both the Wimax and LTE networks are all-IP networks, home NodeBs of the Wimax and LTE networks access a core network via the IP networks, and the Femto GW may not be needed in the practical deployment.
The network elements at the service location in FIG. 1, which are network elements providing services to the user equipment finally, are mainly described above. Before initialization is completed, stored in the Femto AP may be relevant parameters of the network elements at an initial location, such as relevant parameters of a security gateway at the initial location (initial SeGW or initial security gateway for short), a Femto authentication, authorization and accounting system at the initial location (initial Femto AAA for short) and a Femto management server at the initial location (initial FMS for short). The network elements at initial location described above are used for finding the network elements at the service location during the initialization (see FIG. 2 for the particular procedure).
In addition, each network element at the service location in FIG. 1 may be the same network element as that at the initial location, i.e. the service location and the initial location are the same.
FIG. 2 is a flowchart of a method for initializing a Femto AP in the existing technology, in which the Femto AP acquires relevant information of a Femto gateway at a service location (serving Femto GW for short) and completes parameter configuration. As shown in FIG. 2, this procedure comprises the following steps.
At 201, the Femto AP establishes an IP security tunnel with an initial SeGW.
When the Femto AP establishes the IP security tunnel with the initial SeGW, an initial Femto AAA is required to authenticate the Femto AP, referring to relevant documents for the particular procedure.
At 202, the Femto AP sends a TR069 information request message carrying parameters such as an identifier of the Femto AP, location information and an initialization identifier to an initial FMS via the established IP security tunnel.
At 203, the initial FMS authenticates access right of the Femto AP, and returns a TR069 information request response message to the Femto AP upon success of the authentication.
At 204, the initial FMS sends a TR069 setting parameter request message carrying a list of serving FMSs (such as a list of IP addresses of serving FMSs) and also a list of serving SeGWs (such as a list of IP addresses of serving SeGWs) to the Femto AP to establish a new IP security tunnel between the Femto AP and the serving FMS. In addition, the message can also carry a list of serving Femto GWs (such as a list of IP addresses of serving Femto GWs).
At 205, the Femto AP acknowledges information sent by the initial FMS, and returns a TR069 setting parameter response message to the initial FMS after selecting a serving FMS, serving SeGW and serving Femto GW according to this information.
At 206, if the serving SeGW is different from the initial SeGW, then the IP security tunnel between the Femto AP and the initial SeGW is released.
If the serving SeGW is the initial SeGW, the IP security tunnel is not required to be reestablished between the Femto AP and the initial SeGW, and the IP security tunnel between the Femto AP and the initial SeGW is certainly not required to be released.
At 207, if the serving SeGW is different from the initial SeGW, then the Femto AP establishes the IP security tunnel with the initial SeGW.
When the IP security tunnel with the serving SeGW is established, the serving Femto AAA is required to authenticate the Femto AP, referring to relevant documents for the particular procedure.
At 208, the Femto AP sends a TR069 information request message carrying parameters such as the identifier of the Femto AP, an alarm identifier, the location information and initialization identifier to the serving FMS via the established IP security tunnel.
At 209, the serving FMS authenticates access right of the Femto AP, and returns a TR069 information request response message to the Femto AP upon success of the authentication.
At 210, the serving FMS sends a TR069 setting parameter request message to the Femto AP, the message carrying a list of serving SeGWs associated with the serving Femto GWs and configuration parameters and authentication parameters of the Femto AP.
In addition, if the list of serving Femto GWs is not carried in the TR069 setting parameter request message in step 204, then the TR069 setting parameter request message in this step is also required to carry the list of serving Femto GWs.
At 211, the Femto AP acknowledges information sent by the serving FMS, and returns a TR069 setting parameter response message to the serving FMS after selecting a serving SeGW and serving Femto GW according to this information.
At 212, if the serving SeGW selected in step 211 is different from the serving SeGW selected in step 205, then the Femto AP releases the IP security tunnel established in step 207.
FIG. 3 is a flowchart of a method for registrating a Femto AP in the existing technology specifically comprising the following steps.
At 301, the Femto AP acquires configuration parameters and information of a serving Femto GW from a FMS using the procedure shown in FIG. 2.
At 302, the Femto AP establishes an IP security tunnel with a serving SeGW.
If in the initialization procedure shown in FIG. 2, the serving SeGW selected in step 211 is the same as the serving SeGW selected in step 205, then since the IP security tunnel has already been established between the Femto AP and the serving SeGW in step 207, then this step is not required to be performed.
At 303: the Femto AP establishes a reliability transmission session port with the serving Femto GW.
At 304, the Femto AP sends a registration request message containing location information of the Femto AP, an identifier of the Femto AP and execution parameters of the Femto AP to the serving Femto GW via the described session port.
The location information of the Femto AP described above may be one or more of:                macro coverage information detected by the Femto AP (such as cellular information);        geographical location information of the Femto AP (such as global positioning information); and        Internet connection information of the Femto AP (such as an IP address of the Femto AP).        
The identifier of the Femto AP is a globally unified and permanent identifier.
The execution parameters of the Femto AP may be cell information selected by the Femto AP.
At 305a, after receiving the registration request message sent by the Femto AP, a Femto GW performs access control on the Femto AP according to the information carried in this message (e.g., determines whether to allow the Femto AP to operate/register at this location based on the location information in the registration request message); and if the result of the access control is that the Femto GW allows the Femto AP to register, then it returns a registration success response message to the Femto AP.
At 305b, if the Femto GW rejects the registration request of the Femto AP (for example, this registration request is rejected due to congestion of the current network, the Femto AP being in a black list, the Femto AP initiating registration at an unauthorized location, etc.), the Femto GW returns a registration failure message carrying failure reasons to the Femto AP.
FIG. 4 is a flowchart of a method in which a UE registers with a legal core network via a legal Femto AP in the existing technology (i.e. a method in which the UE accesses the network) specifically comprising the following steps.
At 401, the UE establishes a radio resource connection with the Femto AP as a bearer of a signaling message or service data.
At 402, the UE triggers a registration process by sending an initialization non-access layer message (non-access layer message for short) to the Femto AP, and the non-access layer message may be an attachment message, a location update message, a service request message, etc.
At 403, after receiving the non-access layer message sent by the UE, the Femto AP finds that there is no context identifier information of a corresponding user (i.e. it finds that the user has not registered yet), and thus sends a registration request message to a serving Femto GW so as to register the user information with the serving Femto GW.
The described registration request message contains information such as registration type, an identifier of the UE (e.g., International Mobile Subscriber Identity (IMSI) of the UE) and an identifier of the Femto AP.
At 404, the serving Femto GW checks capability of the user accessing the Femto AP, and if the user is allowed to use resources provided by the Femto AP, then it accepts the registration, establishes user context and returns a registration response message carrying the context identifier information of the user to the Femto AP.
At 405, the Femto AP forwards the non-access layer message to the serving Femto GW.
At 406, the serving Femto GW does not process the non-access layer message forwarded by the Femto AP and directly transmits it to a serving core network transparently.
At 407, the serving core network authenticates security of the user according to the received non-access layer message.
At 408, if the security authentication is passed, then the core network side performs corresponding operations on the non-access layer message sent by the user, returns a non-access layer response message to the UE, and sends information of the core network side to the UE. The response message is transparently transmitted between the UE and the CN, and will not processed by both the Femto AP and serving Femto GW.
The existing home NodeB system and procedures of the initialization and registration of the Femto AP and the registration of the UE based on this system are described above.
There is a disadvantage in the existing home NodeB, i.e. one home NodeB can only access one core network, which means that users of one home NodeB usually can only be users of one operator network and users of another operator network cannot access this operator network unless a roaming protocol is subscribed between both operators.
However, usually there is no roaming protocol between two operators under the same coverage, which brings inconvenience to owners of home NodeBs. For example, there are three mobile operators in China, and all these three operators have their own IP backhaul networks which will be evolved to LTE networks in the future. If the three operators all deploy home NodeB systems, for an owner of one home NodeB, users accessing mobile operator networks using this home NodeB include family members and friends of the owner of the home NodeB or temporary visitors, they may belong to operators different from the owner of the home NodeB, and therefore they cannot access the mobile operator networks through this home NodeB. In addition, for enterprise level home NodeB users, in order for users of different operators to access the network, the enterprise needs to purchase home NodeBs of multiple different operators, which will cause resource and space waste.